Subject: LF bit propogation

From: [email-masked]
Date: Tue, 5 Jul 94 18:34:27 EDT

Connect RIGlet,

Here are my responses to the proposal posted by Paul. I am only
including segments from Paul's comments to keep the append short.
My respones are marked with a >>.

>Cache Interaction Issue
>=======================
>
>As Wayne pointed out, if an implementation caches the route to a locally
>accessible MAC or Name and uses this cache to speed the reply to CUR_ex/NNQ_ex
>requests, there is a possibility that the cached route may not be available
>when the CUR_cs is issued, and that any alternative route supports only a
>smaller LF size.
>
>If this does happen, it means that the bridge topology on the Target LAN has
>changed for some reason, probably beacuse of loss of a link or bridge.  With
>this mindset, it seems entirely appropriate to simply fail the circuit setup
>attempt that has hit this problem and flush (or replace) the bad cache entry.
>
>The most obvious and simple way to achieve this for the Target DLSw not to
>issue the ICR_cs if the LF bits on the CUR_cs are incompatible with the route
>it obtains.  However this does imply that if the Origin DLSw also uses a
>cache to speed the reply to TEST frames without issuing a CUR_ex, it must
>retain the LF bits from the ICR_ex for all time until it next fails to set up a
>circuit using the cached data.  A CUR_ex must then be issued for the next TEST
>frame to relearn the new LF bits (and location) of the cached MAC address.
>
>This is slightly complex at first sight - but caching is still optional and if
>you do use it you must be prepared to handle the complexities of relearning bad
>cached data!  Hence this seems like a good general solution.  See the next
>section for one further enhancement that we could also adopt.
>

>>  Paul, I'm okay with this proposal for handling the cache interaction issue. Anything
>>  else would be complicated and probably difficult to implement.

>Cache and XID3s
>===============
>
>If the Origin DLSw is aware that it is dealing with an SNA station that uses
>XID3s (which will be the case if it is issuing the CUR_cs as a result of
>receiving an XID3), it could avoid the failure of the circuit setup attempt by
>modifying the XID3 max BTU size field.  However this requires that the Target
>does not fail the circuit setup attempt if the LF bits don't match.
>
>For this to be possible, let's use one of the reserved bits in Wayne's LF Size
>field to mean "don't care if you return a smaller size".  If this bit, say the
>top bit, is set, it instructs the Target DLSw to use the LF size specified
>in the CUR_cs when issuing the TEST frame, but to return the ICR_cs with
>whatever value is obtained for LF size even if it is smaller.  The Origin DLSw
>is then responsible for deciding whether to drop the circuit by issuing
>a HALT_DL_NOACK or to continue and issue the REACH_ACK.
>
>This bit may also prove useful in the future for other DLC types where the
>Origin DLSw can guarantee that the Origin end station will act on any LF size
>returned on the ICR_cs.
>
>Note that the Origin DLSw is not required to support this use of XID3s (or
>other mechanisms for LF size propagation), but the Target DLSw is required
>to implement the 2 lines of code needed to support this bit flag (in addition
>to the LF Size field support).

>>  Paul, I have 2 comments on the cache and XID3 issue. (1) I think the wording
>>  should not reflect anything about XID3 (or anyi other frame). I suggest the
>>  wording only describe the use of the flag, i.e. OFF means fail connection, ON
>>  means don't fail the connection, but send the LF bits back on the ICANREACH_cs.
>>  (2) If the origin DLSw decides to drop the circuit after requesting the LF bits
>>  back on the ICANREACH (don't care bit set to 1) by issuing a HALT_DL_NOACK, won't
>>  this decision require a change to the DLSw FSMs ?

>
>Minor Issues and comments
>=========================
>
>1)      We should probably specify which SSP frames are required to carry this
>        information.  This informations seems to make sense on CUR, ICR, NNQ,
>        NNR, XIDFRAME, DATAFRAME and DGRMFRAME messages only.
>

>>  Paul, I agree we should specify which SSP frames are required to cary LF bits.
>>  I agree for CUR, ICR, NNQ, NNR, XIDFRAME messages. I'm not sure we need LF bits for
>>  DATAFRAME and DGRMFRAME messages. Can you enlighten me as to why you think we would
>>  need LF bits for these 2 messages ?
>>
>>  I think the CONTACT and CONTACTED SSP messages need to propogate the LF bits. Some
>>  Netbios stations have been rumored to get the LF bits from the SABME/UA exchange.
>>

>2)      Wayne's example flows below include the use of a TEST cmd/rsp pair
>        after the receipt of an ICR_cs.  This corresponds to how the 6611 (and
>        RFC 1434) currently works but it is not required if the Origin DLSw has
>        retained the RIF from the XID/NQ that initiaited the CUR_cs.
>

>> That is correct  ....

>3)      I suggest we reverse the bit order (or the labelling of the bits!) to
>        put the LF bits in the least-significant 6 bits of the byte as this is
>        marginally earier to parse.
>

>>  Okay. My bit labeling was intended to suggest the LF bits would be the least
>>  significant bits.

>>  Why the base and extended LF bits ?
>>
>>  The base and extended bits for the LF field are needed to support
>>  the new Largest Frame Sizes. These new LF sizes are for Source Routing Bridges
>>  as well as for Source Routing Transparent Bridges (SRT). As bridge and end station
>>  vendors begin to implement the new LF capabilities, DLSw will not be able to take
>>  advantage of these new sizes, because they don't understand the encoding.
>>  Refer to IEEE 802.1D Standard, Annex C for encoding of Largest Frame
>>  base and extended bit values.

>>  Wayne T.

---

From: Gnanaprakasam Pandian <[email-masked]>
Date: Fri, 15 Jul 94 17:24:30 PDT

Hi,
Just wondering what the header format(CONTROL versus INFO) 
is for CapXchg and IFCM SSP messages.
They are brand new additions to the rel 1 spec and were
never part of RFC 1434.

Whatever we choose should not have any
interoperability issues, I guess.
Pl. correct me if someone had already put some code around it
and do not want to change.

I propose we use 16 byte info headers on them.
The rationale is the following :
CapXchg - We care only about the CVs in the data area
          and whatever we put in the header 
	  is going to get thrown away, anyway. True?
IFCM    - I am assuming that it will kick in only after circuit ids
          are resolved(DLC corr+DLC port).

	  Does it have any implications on the new proposal from Gene
	  which allows more control frames to carry the flow control
	  operators.

-- 
G. Pandian           + Gnanaprakasam Pandian      +
Cisco Systems, Inc.  + Software Engineer          +           
1525 O'Brien Drive   + Phone : (415)688-7684      +
Menlo Park,          + FAX   : (415)688-8282      +
CA 94026             + E-mail: [email-masked] +